Thank you for this! What do you think about accepting an object for headers, e.g.

file.getSignedUrl({
  extensionHeaders: {
    'x-goog-acl': 'public-read',
    'x-goog-meta-foo': 'bar'
  },
  // ...

File.prototype.getSignedUrl = function(options, callback) {
  ...

  var extensionHeadersString;

  if (options.extensionHeaders) {
    for (var headerName in options.extensionHeaders) {
      extensionHeadersString += format('{name}:{value}\n', {
        name: headerName,
        value: options.extensionHeaders[headerName]
      });
    }
  }

  ...
};

@stephenplusplus I also thought that an object would be better, but I thought about maintaining backwards compatibility and that it would be easier to fix the existing interface (extension headers represented by a string) if it's supposed to be supported in the future.

If backwards compatibility doesn't matter, I'd definitely prefer representing extension headers just as an object.

Thank you for thinking about the backwards compatibility issue, but it's okay to break it if we've discovered an easier API. We will just bump the minor to follow along with semver.

Do you want me to update the PR to represent extension headers as an object then, @stephenplusplus?

If you're up for it, that would be great 👍

Will do then.

@stephenplusplus Done!

Merged in via 17e510b. Thanks again @aknuds1!